A typical database cluster includes a plurality of database servers, which are often distributed geographically. In the database cluster, the database servers communicate with each other for data replication and data synchronization purposes. The term “data replication” typically refers to electronic copying of data from one computer or server to other computers or servers. Data replication and data synchronization enable users to access a same level of information and to access data relevant to their tasks without interfering with tasks of other users.
Conventionally, a database server reserves a space in its system memory to perform operations on data. This reserved space is called by different names in different database management systems (DBMS), but is generally called a “buffer pool”. If the data does not fit fully in a buffer pool, a DBMS in a course of operation will have to replace unneeded database pages in the buffer pool with needed database pages from the data stored on a persistent storage device (hereinafter referred to as “buffer pool page replacement”).
Buffer pool page replacement is a very expensive operation. Firstly, storage device access latencies are orders of magnitude higher than memory access latencies, while storage device access throughput is orders of magnitude lower than memory access throughput. Secondly, as there is no generally efficient way to cache data, the needed database pages have to be read from the storage device. Therefore, for dedicated database servers, system administrators often try to make their buffer pool as large as possible to reduce a need for page replacements.
However, data size often significantly exceeds a buffer pool capacity, which is typically limited by an available memory size. As a consequence, buffer pool page replacement is a common situation in most practical implementations.
Moreover, buffer pool page replacement poses a severe problem during database replication at slave servers. When a transaction is replicated from a master server to a slave server, following happens:
(i) the master server has already fetched all required database pages from its storage device into its buffer pool and has completed the transaction, and
(ii) the slave server only now starts to apply the transaction and fetch required database pages from its storage device.
Thus, the master server has already performed most of its computation-intensive work, while the slave server still needs to fetch the required database pages to modify them according to results of the master server. As a result, the slave server starts to lag behind the master server, and buffer pool page replacement is a major contributing factor to it.
There exists some conventional techniques that attempt to solve the abovementioned problem. These conventional techniques involve pre-fetching database pages into a buffer pool for already replicated transactions that reside in a slave server's staging area waiting to be applied in its DBMS. However, this type of pre-fetching is effective only when the slave server is already lagging behind and a queue of incoming replication transactions is long enough to allow time for the pre-fetching.